Layered ArchitectureのLayer構造の意味

外側は変更されやすく、内側は変更されにくい

外側が変更された時、内側はそれを気にする必要はないような依存関係を目指している

逆に内側が変更されると、外側がみんな影響を食らう

これは仕方がない。

変更されやすさに順序を付けてそれをレイヤーにすることで、全体としての変更されやすさを抑えていている

The Clean Architecture.icon

最も外側が、最も変更されやすい

外部のサービスと結びついているから

例えばViewとかは顕著

ブラウザが異なったら、見え方も異なる

OSが異なったら、見え方も異なる

細かい見た目の変更によっても修正される

みたいなことがしょっちゅう起こってる

壊れやすい、不安定

IOと関わるものが最も不安定になる

最も中心が、最も変更されづらい

もちろん機能追加などがあればそこにmethodを加えることもあるが、既存のものにはあまり触れない

なので、この世界では、ここだけに集中したい

周囲の世界であるOSとかブラウザとか外部サーバー等のごたごたを考えたくない

抽象化して見ると、内側こそがアプリケーションそのものであり、

より外側のものは全て「それのプラグイン」と考えることができる

ビジネスロジックは替えが効かないが、RDBMSやViewは何にでも変更可能

以下の課題は個別に問題視すれば別にレイヤードにはならないはず

これらを総合的に解決するアーキテクチャとして、Layeredにするのが適している

凝集させる

レイヤー構造になっていようと、同じファイルに書くこともできるし、各機能を関数で書いていれば明示的なレイヤーは消える

一般的なWebアプリケーションならCAとかに倣っておけばだいたい耐えるんだろうけど、ちょっと変わったことをやるプロダクトなら、「どういうふうにレイヤーを分けるか」というめちゃくちゃ重要な問題が出てくる

レイヤードアーキテクチャはOSとかでもあるし

Entity部の設計がおかしいと、プロダクト全体が辛くなる

と、思ったが、

「依存を集中することを避ける」思想ならば、そうはならない？とかある？